home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
-
- Network Working Group C. Hedrick
- Request for Comments: 1080 Rutgers University
- November 1988
-
-
- Telnet Remote Flow Control Option
-
- Status of This Memo
-
- This RFC specifies a standard for the Internet community. Hosts on
- the Internet that do remote flow control within the Telnet protocol
- are expected to adopt and implement this standard. Distribution of
- this memo is unlimited.
-
- Motivation
-
- This memo describes a method of remotely toggling flow control
- between a user telnet process and the attached terminal. Only flow
- control of data being transmitted from the telnet process to the
- terminal is considered. Many systems will also allow flow control of
- data from the terminal to the telnet process. However there is
- seldom need to change this behavior repeatedly during the session.
-
- There are two common ways of doing flow control: hardware and
- software. Hardware flow control uses signals on wires dedicated for
- this purpose. Software flow control uses one or two specific
- characters sent along the same path as normal input data. Most
- commonly, XOFF (control-S) and XON (control-Q) are used to stop and
- start output, respectively. The option described herein is useful
- primarily where software flow control is being used. (Since hardware
- flow control does not preempt any characters, there is normally no
- need to disable it.)
-
- The primary difficulty with software flow control is that it preempts
- one or two characters. Host software often requires the user to be
- able to input every possible ASCII character. (Certain editors are
- notorious for having XOFF and XON as commonly-used commands.) For
- this reason, operating systems often allow programs to disable flow
- control. While it is disabled, the characters that normally signal
- flow control may be read as normal input. In a telnet environment,
- flow control is normally done by the user telnet process, not by the
- host computer. Thus this RFC defines a way to propagate flow control
- status from the host computer to the user telnet process.
-
-
-
-
-
-
-
-
- Hedrick [Page 1]
-
- RFC 1080 Telnet Remote Flow Control Option December 1988
-
-
- 1. Command Name and Code
-
- TOGGLE-FLOW-CONTROL
-
- Code = 33
-
- 2. Command Meanings
-
- IAC WILL TOGGLE-FLOW-CONTROL
-
- Sender is willing to enable and disable flow control upon
- command.
-
- IAC WON'T TOGGLE-FLOW-CONTROL
-
- Sender refuses to enable and disable flow control. Nothing is
- implied about whether sender does or does not use flow control.
- It is simply unwilling to enable and disable it using this
- protocol.
-
- IAC DO TOGGLE-FLOW-CONTROL
-
- Sender is willing to send commands to enable and disable flow
- control.
-
- IAC DON'T TOGGLE-FLOW-CONTROL
-
- Sender refuses to send command to enable and disable flow
- control.
-
- IAC SB TOGGLE-FLOW-CONTROL OFF IAC SE
-
- Sender requests receiver to disable flow control. The code for
- OFF is 0.
-
- IAC SB TOGGLE-FLOW-CONTROL ON IAC SE
-
- Sender requests receiver to enable flow control. The code for
- ON is 1.
-
- 3. Default
-
- WON'T TOGGLE-FLOW-CONTROL
-
- Flow control information will not be exchanged.
-
-
-
-
-
-
- Hedrick [Page 2]
-
- RFC 1080 Telnet Remote Flow Control Option December 1988
-
-
- DON'T TOGGLE-FLOW-CONTROL
-
- Flow control information will not be exchanged.
-
- 4. Description of the Option
-
- Use of the option requires two phases. In the first phase, the
- telnet processes agree that one of them will TOGGLE-FLOW-CONTROL.
- WILL and DO are used only in this first phase. In general there will
- be only one exchange of WILL and DO for a session. Subnegotiations
- must not be issued until DO and WILL have been exchanged. It is
- permissible for either side to turn off the option by sending a WONT
- or DONT. Should this happen, no more subnegotiations may be sent,
- unless the option is reenabled by another exchange of DO and WILL.
-
- Once the hosts have exchanged a WILL and a DO, the sender of the DO
- TOGGLE-FLOW-CONTROL is free to send subnegotiations to enable and
- disable flow control in the other process. Normally, the sender of
- the DO will be a host, and the other end will be a user telnet
- process, which is connected to a terminal. Thus the protocol is
- normally asymmetric. However it may be used in both directions
- without confusion should need for this arise.
-
- As soon as the DO and WILL have been exchanged, the sender of the
- WILL must enable flow control. This allows flow control to begin in
- a known state. Should the option be disabled by exchange of DONT and
- WONT, flow control may revert to an implementation-defined default
- state. It is not safe to assume that flow control will remain in the
- state requested by the most recent subnegotiation.
-
- Currently, only two command codes are defined for the
- subnegotiations: flow control off (code 0) and flow control on (code
- 1). Neither of these codes requires any additional data. However it
- is possible that additional commands may be added. Thus
- subnegotiations having command codes other than 0 and 1 should be
- ignored.
-
- Here is an example of use of this option:
-
- Host1: IAC DO TOGGLE-FLOW-CONTROL
-
- Host2: IAC WILL TOGGLE-FLOW-CONTROL
-
- (Host1 is now free to send commands to change flow control.
- Note that host2 must now have enabled flow control.)
-
-
-
-
-
-
- Hedrick [Page 3]
-
- RFC 1080 Telnet Remote Flow Control Option December 1988
-
-
- Host1: IAC SB TOGGLE-FLOW-CONTROL OFF IAC SE
-
- Host1: IAC SB TOGGLE-FLOW-CONTROL ON IAC SE
-
- Author's Address:
-
- Charles Hedrick
- Rutgers University
- Center for Computer and Information Services
- Hill Center, Busch Campus
- P.O. Box 879
- Piscataway, NJ 08855-0879
-
- Phone: (201) 932-3088
-
- Email: HEDRICK@ARAMIS.RUTGERS.EDU
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Hedrick [Page 4]
-